In test cases testNIP01SendTextNoteEventGeoHashTag, testNIP01SendTextNoteEventHashtagTag, testNIP01SendTextNoteEventCustomGenericTag, testFiltersListReturnSameSingularEvent, testFiltersListReturnTwoDifferentEvents, and testMultipleFiltersDifferentTypesReturnSameEvent, the published events are never purged from the relay, and the expression assertEquals(2, result.size()); will always fail if you run the test cases more than once.
To prevent this, you have to make the content unique, for example, I am introducing the index variable like this, to ensure that the variables geoHashTagTarget and genericTagTarget are unique:

    @Test
    public void testMultipleFiltersDifferentTypesReturnSameEvent() throws IOException {
        System.out.println("testMultipleFilters");

        Long index = System.currentTimeMillis();
        String geoHashTagTarget = "geohash_tag-location-DifferentTypesReturnSameEvent" + index;
        GeohashTag geohashTag = new GeohashTag(geoHashTagTarget);

        String genericTagTarget = "generic-tag-value-DifferentTypesReturnSameEvent" + index;
        GenericTag genericTag = GenericTag.create("m", genericTagTarget);

        NIP01<NIP01Event> nip01 = new NIP01<>(Identity.generateRandomIdentity());
        nip01.createTextNoteEvent(List.of(geohashTag, genericTag), "Multiple Filters").signAndSend(relays);

        Filters filters = new Filters(
                new GeohashTagFilter<>(new GeohashTag(geoHashTagTarget)),
                new GenericTagQueryFilter<>(new GenericTagQuery("#m", genericTagTarget)));

        List<String> result = nip01.sendRequest(filters, UUID.randomUUID().toString());

        assertFalse(result.isEmpty());
        assertEquals(2, result.size());
        assertTrue(result.stream().anyMatch(s -> s.contains(geoHashTagTarget)));

//        nip01.close();
    }

Thoughts?

ah, yes- considering some common testing-related semantics:

• integration testing: definition/practice/expectation is for a system under test to have predefined/known state before tests are started, including any/all data. existing nostr-java (and SC) integration tests are implemented as per this definition.

• end-to-end/functional testing: aligns with what you're describing (tests using persistent/ongoing data/states) as conventional/practice. i'm open to whatever semantics you prefer, but given the above definition- we haven't (yet) implemented a testing scenario as you've described.

if helpful/useful, i've just pushed an automated integration-test bash script into sc_spring_boot-gradle-migration branch that might help streamline/simplify your integration testing process.

prior to use, note the requisite configuring relevant nostr-java & SC directories

w/ abbreviated main logic as follows:

1. cd to nostr-java
2. rm m2_local
3. build_nostr-java
4. publish nostr-java to m2_local
5. cd to superconductor
6. build and test super
7. start super_service
8. run nostr-java tests
9. terminate super

supplemental, if integration testing with SC as your relay server: as SC develop branch is currently several commits ahead of nostr-java PR branch, you'll either want to use:

• SC commit 614686786e7009b2afcd989a4a1e76159b3ecd64

or

• nostr-java develop-branch compatible sc_spring_boot-gradle-migration branch, which includes both autotest.sh script (+ newly added maven option) and maven failsafe retry activated for "flaky" tests.

testNIP99CalendarContentPreRequest fails on my machine.

    assertTrue(
        JsonComparator.isEquivalentJson(
            MAPPER_AFTERBURNER.readTree(expected),
            MAPPER_AFTERBURNER.readTree(reqResponse)));

org.opentest4j.AssertionFailedError: expected: but was:
at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:183)
at app//nostr.api.integration.ApiNIP52RequestIT.testNIP99CalendarContentPreRequest(ApiNIP52RequestIT.java:142)
at java.base@21.0.6/java.lang.reflect.Method.invoke(Method.java:580)
at java.base@21.0.6/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
at java.base@21.0.6/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
at java.base@21.0.6/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
at java.base@21.0.6/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
at java.base@21.0.6/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)

gotcha, can you post/send the test-command executed and full stacktrack/debug-output for that test class?

somewhat related if you haven't yet encountered- any integration test class using websockets are necessarily multi-threaded with multiple concurrent websocket connections. this can/may lead to concurrency states for both websocket connections and database state and as a result, it is not uncommon for a test method to fail. these failures are false-positives and rectifiable by activating (uncommenting) gradle's retry pass